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Introduction 


Overview 

This  is  the  phase  II  report  documenting  the  combat  emergency 
medicine  expert  system  (CEMES)  project.  The  work  presented  in 
this  report  covers  the  complete  exploratory  development  of  CEMES 
conducted  from  November  1985  to  April  1987.  The  CEMES  project  is 
the  core  effort  within  the  artificial  intelligence  research  pro¬ 
gram  being  conducted  at  the  U.S.  Army  Aeromedical  Research  Labor¬ 
atory  .  1 

The  theoretical  background  and  feasibility  analysis  for  the 
CEMES  project  was  completed  in  September  1985  under  the  In-House 
Laboratory  Independent  Research  (ILIR)  program  and  documented  in 
Landon  (1986) .  The  feasibility  study  outlined  the  concept 
development  underlying  the  CEMES  project  in  addition  to  providing 
a  general  review  of  artificial  intelligence  and  existing  medical 
expert  systems.  Two  previous  reports  (Landon,  1987a,  1987b) 
documented  the  CEMES  project  at  the  completion  of  Phase  I  as 
interim  progress  reports. 

The  CEMES  project  is  documented  in  three  separate  reports. 
This  report  outlines  the  rationale,  general  operation,  and  final 
design  concepts  underlying  the  CEMES  system  and  project.  A  second 
report  (Landon,  1987c)  documents  the  CEMES  programs,  program  code, 
and  other  specifics  of  CEMES  construction.  The  second  report 
exists  primarily  for  archival  purposes  and  is  not  required  for 
reference  when  reading  this  report. 


Military  relevance 

Army  21  operational  doctrine  anticipates  a  complex,  fluid, 
and  chemical,  biological,  and/or  radiological  (CBR)  contaminated 
battlefield  expected  to  produce  mass  casualties.  The  expertise  of 
physicians  and  other  medical  personnel  will  be  needed  at  all 
battlefield  levels  to  reduce  medical  complications  and  prevent 
avoidable  deaths.  However,  the  nature  of  the  battlefield  and 
anticipated  lack  of  numerical  superiority  in  both  land  and  air 


1  DD  Form  1498,  Artificial  Intelligence  and  Robotics: 
Biomedical  Applications,  Project  Number  3E16277A879,  Work  Unit 
Number  167.  Protocol  titled  "Investigation  and  Exploratory 
Development  of  Medical  Expert  Systems  for  Military  Applications" 
dated  22  March  1985  and  approved  19  July  1985. 
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forces  may  prevent  quick  and  efficient  casualty  evacuation. 

Rapid  and  expert  care  will  be  necessary  for  casualty  survival  and 
potential  return  to  duty.  Lack  of  personnel  will  make  it  unfeas¬ 
ible  to  assign  the  required  numbers  of  physicians  at  all  battle¬ 
field  levels  as  necessary  to  provide  the  appropriate  medical 
care.  In  addition,  casualties  among  medical  personnel  would 
aggravate  the  effects  of  mass  casualty  situations. 

The  Medical  Systems  Program  Review  (Robertson  and  Glazier, 

1985)  outlined  a  new  battlefield  medical  care  strategy.  This 
strategy  included  a  continuum  of  care  from  the  forward  line  to 
the  continental  United  States.  A  casualty  would  "flow"  through 
the  continuum  only  so  far  as  his  injury (s)  dictated  and  then  he 
would  be  returned  to  duty  as  soon  as  possible.  Combined  with  the 
continuum  of  care  was  the  idea  of  far  forward  care,  where  first 
aid  and  trauma  care  would  be  administered  as  far  forward  in  the 
continuum  of  care  as  possible.  Technological  advances  in  emer¬ 
gency  medicine  would  enhance  the  implementation  and  effectiveness 
of  the  continuum  and  far  forward  care  concepts. 

Artificial  intelligence  has  been  designated  as  one  of  the 
Army's  major  research  and  development  thrust  areas,2  with  arti¬ 
ficial  intelligence-based  medical  systems  a  major  subarea.3  Al¬ 
though  medical  expert  systems  have  been  developed  and  used  for 
academic  research,  there  have  been  few  attempts  at  developing 
this  technology  for  military  medical  applications.  The  likeli¬ 
hood  of  successful  attainment  of  the  medical  and  health  care 
mission  could  be  enhanced  through  artificial  intelligence  systems 
that  both  diagnose  and  treat  casualties.  In  addition,  a  properly 
designed  and  implemented  medical  expert  system  could  bring  to  the 
battlefield  health  care  capabilities  currently  available  only 
from  specialists  in  rear  echelon  facilities.  Such  systems  also 
could  serve  as  aids  to  physicians  during  peacetime. 


2  The  Militarily  Critical  Technologies  List,  Office  of  the 
Under  Secretary  of  Defense,  Research,  and  Engineering, 
Washington,  D.C.,  October  1985,  paragraph  1.3.3. 

3  Combat  Service  Support  Mission  Area  Analysis  -  Level  II, 
Vol  1:  Executive  Summary,  January  1983,  pages  14a-14b, 
paragraph  15.  Also  see  the  study  on  artificial  intelligence  by 
the  National  Research  Council  (1983) . 
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System  concept 


Background 

Artificial  intelligence  (AI)  is  a  term  used  to  refer  to  the 
discipline  within  cognitive  science  devoted  to  the  attempt  to 
program  computers  to  perform  tasks  usually  thought  of  as  requir¬ 
ing  some  measure  of  intelligence  (indicated  by  a  human's  unique 
ability  to  accomplish  the  same  task) .  General  research  in  AI  has 
resulted  in  the  technological  capability  for  producing  limited 
domain,  but  sophisticated,  problem  solving  programs.  These  pro¬ 
grams  are  known  collectively  as  expert  systems  because  they  at¬ 
tempt  to  duplicate  or  emulate  human  expert  abilities  within  some 
well-defined  domain. 

The  specific  design  and  implementation  of  any  particular  expert 
system  is  unique  to  that  system.  The  technical  aspects  of  gen¬ 
eral  expert  system  design  were  reviewed  in  the  CEMES  feasibility 
study  (Landon,  1986).  The  specific  aspects  of  CEMES'  preliminary 
design  were  covered  in  the  Phase  I  interim  reports  (Landon,  1987, 
Landon,  1988a) .  The  final  design  and  operation  of  CEMES  is  docu¬ 
mented  in  this  report. 


CEMES  medical  domain  of  operation 

CEMES  task  domain  is  emergency  medicine  diagnosis  and  treatment 
of  casualties  with  respect  to  hemorrhagic  shock  and  chemical 
agent  contamination  prior  to  receiving  definitive  care.  That  is, 
CEMES  is  designed  to  provide  limited  casualty  care  management 
with  the  goal  of  reducing  morbidity  rates  due  to  hemorrhage  and 
shock.  The  importance  and  critical  nature  of  hemorrhage  and 
shock  with  respect  to  the  morbidity  rate  of  casualties  was 
pointed  out  by  Bellamy  (1984)  in  an  analysis  of  the  causes  of 
death  in  conventional  land  warfare: 

"First  and  foremost,  there  is  a  need  to  improve  the 
field  management  of  hemorrhage.  The  combination  of 
simple  first  aid  measures  plus  infusion  of  an  oxygen¬ 
carrying  solution  and/or  use  of  pharmacologic  inter¬ 
ventions  designed  to  optimize  cardiac  output  (anti- 
shock  drugs)  might  be  lifesaving  in  a  surprisingly 
large  number  of  casualties."  (pg.  61) 

The  primary  objectives  in  emergency  medicine  are  resuscitation 
and  stabilization  pending  a  complete  diagnosis  and  determination 
of  disposition  at  a  definitive  care  facility.  Initial  resus- 
citative  measures  and  battlefield  first  aid  must  be  accomplished 
by  the  platoon  medic,  medic  extender,  or  a  physician.  The  ex¬ 
tensive  hands-on  requirements  for  first  aid  measures  preclude  the 
use  of  an  automated  system  (i.e.,  although  great  advances  have 
occurred  in  robotics,  a  robotic  hand  with  the  sensitivities  and 
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dexterity  of  the  human  hand  has  yet  to  be  devised) .  However, 
once  a  casualty  is  attached,  an  automated  system  could  provide 
limited  aid  to  a  physician  or  medic  in  any  future  resuscitative 
measures  that  might  be  required. 


CEMES  military  operational  requirements 

The  prevalent  operational  environment  for  CEMES  is  dictated  by 
military  requirements.  Following  military  doctrine  (Department 
of  the  Army,  FM  100-5,  FM  8-10;  Cook,  1984;  Robertson  and 
Glazier,  1985) ,  several  operational  and  environmental  assumptions 
that  have  governed  the  design  of  CEMES  are: 

1.  The  system  should  be  capable  of  operating  within  a  CBR  con¬ 
taminated  battlefield,  requiring  diagnosis  and  treatment  of  CBR 
contaminated  casualties. 

2.  Expendable  supplies  (e.g.,  IV  fluid)  may  be  extremely  lim¬ 
ited,  placing  a  high  value  on  economy  of  supply  use  and  efficient 
treatment  strategies. 

3.  Qualified  maintenance  personnel  may  not  be  present,  requir¬ 
ing  the  system  to  be  self-diagnosing  to  compensate  for  damaged  or 
inoperative  subassemblies  (i.e.,  degraded  mode  operation). 

4.  Immediate  casualty  evacuation  will  not  necessarily  be 
available,  requiring  long-term  casualty  care  up  to  48  hours. 

Although  the  above  four  operational  assumptions  are  not  exhau- 
tive,  they  cover  the  major  aspects  of  design  that  are  somewhat 
unique  to  the  military.  The  implications  of  these  requirements 
for  CEMES'  design  were  examined  in  the  feasibility  study  (Landon, 
1986)  . 

It  is  anticipated  that  CEMES  could  be  deployed  as  far  forward 
as  the  battalion  aid  station.  A  CEMES  unit  could  function  in  a 
multicasualty  mode,  where  a  single  CEMES  system  monitors  several 
casualties,  or  in  a  single  casualty  mode,  where  each  casualty  has 
a  unique  CEMES  unit.  The  latter  case  is  more  likely.  That  is,  a 
single  casualty,  battery-operated  CEMES  unit  could  be  incorpor¬ 
ated  into  a  stretcher  or  other  suitable  transport  device  and  be 
evacuated  with  the  casualty  until  definitive  care  is  reached. 
Add-on  modules  could  provide  increasingly  sophisticated  medical 
capabilities  as  the  casualty  moves  through  the  evacuation  system, 
possibly  to  the  point  of  providing  the  casualty  with  his  own 
personalized  mobile  critical  care  unit. 
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Outline  of  CEMES  operation 

The  central  design  principle  underlying  CEMES  is  that  of  being 
a  totally  self-contained,  closed-loop  system.  For  this  purpose, 
closed-loop  expert  systems  were  defined  as  systems  that  require 
little  or  no  human  intervention  to  accomplish  their  objectives 
(Landon,  1986) .  For  an  emergency  medicine  expert  system,  this 
implies  that  both  diagnosis  and  treatment  of  emergency  medical 
conditions  is  accomplished  by  the  expert  system.  Therefore, 
strict  closed-loop  operation  requires  the  system  to  operate  in 
the  absence  of,  or  in  lieu  of,  an  attending  physician,  although  a 
human  assistant  will  be  needed  to  attach  biomedical  sensor/treat¬ 
ment  equipment  and  replace  expendable  supplies.  However,  CEMES 
was  designed  to  be  more  of  a  sophisticated  medical  assistant,  de¬ 
creasing  physician  or  medic  workload  by  having  some  elements  of 
autonomy  and  not  requiring  continuous  human  interaction. 

The  closed-loop  aspect  of  CEMES  operation  is  implemented  in  a 
process  control  loop  (which  will  be  explained  more  completely  in 
the  section  "The  CEMES  expert  system") .  To  provide  a  preliminary 
overview,  the  major  processing  events  in  the  CEMES '  closed-loop 
cycle  are: 

1.  CEMES  first  obtains  vital  sign  data  automatically  through 
noninvasive  biomedical  sensors  attached  to  the  casualty.  A  pre¬ 
liminary  analysis  is  conducted  to  determine  if  the  data  is  valid 
(e.g.,  within  acceptable  human  physiological  limits).  In  add¬ 
ition,  an  attending  medic  or  physician  can  indicate  whether  or 
not  chemical  agent  contamination  is  present  or  suspected.  This 
design  consideration  aids  in  workload  reduction  by  not  requiring 
attending  personnel  to  continually  be  available  for  data  entry  to 
the  system. 

2.  Following  data  collection,  CEMES  determines  a  diagnosis 
with  respect  to  shock  and/or  chemical  agent  contamination  and 
determines  a  preliminary  treatment  recommendation  based  on  the 
diagnosis.  CEMES  treatments  are  limited  to  IV  fluid  infusion  and 
atropine  drug  injections  administered  intravenously  through  the 
IV  line.  The  final  IV  infusion  rate  and  atropine  dose  is  deter¬ 
mined  later  in  the  cycle. 

3.  Following  the  diagnosis,  CEMES  examines  the  casualty's 
vital  sign  history  for  trends.  The  trend  analysis  can  have  three 
directions  (improving,  deteriorating,  or  unchanging)  and  two  mag¬ 
nitudes  (catastrophic  and  gradual)  for  a  total  of  five  trend  out¬ 
comes.4  Trends  are  established  both  by  examining  directionality 
of  vital  signs  over  time  and  by  relationships  between  consecutive 
diagnoses  over  time.  For  example,  class  three  hemorrhagic  shock 
obviously  is  worse  than  class  one  hemorrhagic  shock,  and  so  a 


4  The  unchanging  trend  direction  has  no  magnitude. 
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casualty  that  jumps  to  class  three  shock  directly  from  class  one 
shock  is  deteriorating  rapidly.  CEMES  recognizes  these  relation¬ 
ships  and  takes  appropriate  actions  based  on  them. 

4.  Prior  to  determination  of  a  final  treatment  regimen,  a  log¬ 
istical  analysis  is  completed  to  determine  IV  fluid  and  line 
status,  the  amount  of  fluid  remaining,  and  anticipated  fluid  need 
based  on  preliminary  treatment  recommendations.  For  example,  the 
preliminary  treatment  recommendation  may  require  IV  fluid  infu¬ 
sion  when  no  IV  line  has  been  established.  The  logistical  analy¬ 
sis  recognizes  this  potential  problem,  provides  the  necessary 
messages  to  the  medic  or  physician  to  establish  an  IV  line,  and 
inhibits  other  CEMES  systems  from  assuming  that  an  appropriate 
treatment  is  being  administered  until  an  IV  line  has  in  fact  been 
established. 

5.  CEMES  concludes  an  operation  cycle  by  establishing  a  final 
treatment  (i.e.,  IV  fluid  infusion  rate  and/or  atropine  dose), 
updating  the  medical  history,  and  providing  the  appropriate 
signals  to  the  biomedical  hardware  to  effect  the  actions  CEMES 
has  determined  are  necessary.  CEMES  then  recycles  after  a  1 
minute  real-time  interval. 
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CEMES  general  design 


Conceptual  organization 

The  conceptual  organization  of  CEMES  is  shown  "in  Figure  1. 

CEMES  is  organized  around  a  blackboard  (Erman  and  Lessor,  1975; 
Hayes-Roth,  1985)  which  is  a  shared  data  structure  accessible  to 
all  of  the  CEMES  subsystems.  The  core  of  CEMES  consists  of  the 
management,  logistics,  trend,  diagnostics,  and  treatment  sub¬ 
systems.  These  five  subsystems  comprise  the  main  expert  system 
responsible  for  governing  CEMES7  operation.  They  are  directly 
analogous  to  the  knowledge  sources  used  in  standard  blackboard- 
based  expert  systems,  obtaining  input  from  and  recording  output 
on  the  blackboard.  These  five  subsystems  are  responsible  for 
completing  the  diagnosis,  constructing  the  IV-based  treatment 
regimen,  watching  for  trends,  and  managing  the  general  operation 
of  the  entire  system.  These  five  subsystems  and  their  operation 
as  an  expert  system  will  be  explained  in  depth  in  the  section 
"The  CEMES  expert  system." 

The  sensor  and  effector  subsystems  are  separate  both  physically 
and  logically  from  the  core  expert  system  subsystems.  The  sensor 
subsystem  includes  the  necessary  hardware  and  software  for  sens- 


Figure  1.  CEMES  conceptual  organization. 
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ing  and  translating  biomedical  signals  into  a  numerical  form 
suitable  for  analysis  by  the  core  expert  system.  Some  of  this 
technology  now  is  available  using  off-the-shelf  medical  equip¬ 
ment.  The  available  equipment  usually  includes  .the  necessary 
algorithms  for  translating  the  raw  signals  into  'some  standard  or 
useful  form  along  with  a  capability  for  sensing  improper  trans¬ 
ducer  attachment  and  simple  malfunctions.  The  analysis  of  the 
validity  of  the  sensor  data  is  accomplished  by  the  core  expert 
system. 

The  effector  subsystem  consists  of  the  appropriate  hardware  and 
software  to  govern  electronically  controlled  IV  fluid  admini¬ 
strators.  Its  primary  function  is  as  a  delivery  mechanism  for 
the  IV-based  treatment  regimens.  This  type  of  equipment  usually 
includes  capabilities  for  sensing  blockages  and  other  malfunc¬ 
tions  in  IV  fluid  delivery.  The  operation  of  the  sensor  and 
effector  subsystems  will  be  explained  in  depth  in  the  section 
"The  CEMES  front-end." 


Laboratory  equipment5 

The  exploratory  development  of  CEMES  was  conducted  using  a 
Hewlett-Packard  (HP)  9000,  Model  520,  general  purpose  mini¬ 
computer  with  the  HP  BASIC  operating  system,  and  a  Symbolics  3640 
standalone  LISP  machine  with  the  Symbolics  LISP  operating  system. 
Figure  2  provides  a  diagram  showing  the  relationship  between 
these  computers,  various  other  CEMES  equipment,  and  the  CEMES 
subsystems  shown  in  Figure  1. 

The  core  expert  system  portion  of  CEMES  is  programmed  in  LISP 
on  the  Symbolics  3640  LISP  machine.  The  LISP  language  was 
selected  due  to  its  close  connection  with  artificial  intelligence 
development  and  the  object-oriented  programming  style.  The 
sensor  and  effector  front-end  subsystems  were  programmed  in  BASIC 
on  the  HP  9000  minicomputer  to  facilitate  real-time  input/output 
and  signal  processing  operations.  In  addition,  the  HP  9000  pro¬ 
vides  the  operator  interface  functions  and  the  necessary  communi¬ 
cations  capabilities  for  the  CEMES'  color  graphic  display. 

An  HP  6942A  multiprogrammer  was  used  to  provide  the  required 
analog-to-digital ,  digital-to-analog,  and  other  hardware  and 
software  functions  for  interfacing  the  vital  sign  simulation 
equipment  and  IV  pumps  to  the  CEMES  computers.  A  Bio-tek  Lion- 
heart  Model  MPS-I  multiparameter  simulator,  a  Dynatech  Model  211A 
patient  simulator,  and  some  custom-built  equipment  provided  sim¬ 
ulation  capabilities  for  the  sensor  subsystem.  Two  FMI  Model  QA 
600  laboratory  general  purpose  pumps  provided  IV  fluid  infusion 


5  A  list  of  manufacturers  is  provided  in  Appendix  A. 
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Figure  2 .  Laboratory  equipment  and  CEMES  subsystem  relation¬ 
ships  . 


simulation  capabilities  for  the  effector  subsystem.  The  wiring 
and  circuit  diagrams  for  the  front-end  equipment  are  provided  in 
Landon  (1988b) . 


Detailed  design  chart  and  design  methodology 

Detailed  organizational  master  charts  of  CEMES  are  provided  in 
Figures  3a  and  3b.  The  charts  in  Figures  3a  and  3b  break  down 
CEMES '  organization  in  terms  of  equipment,  subsystem,  subsystem 
communications  and  information  flow,  and  central  aspects  of  the 
programming  design  of  each  subsystem.  The  actual  flow  charts  and 
code  for  each  subsystem  are  documented  in  Landon  (1988b) .  The 
charts  in  Figures  3a  and  3b  diagram  relationships  and  design 
details  to  aid  in  the  explanation  of  CEMES'  design  and  operation 
in  the  following  sections. 
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CEMES  FRONT-END  ON  HP  9000  MODEL  520  MINICOMPUTER 


Front-End 
Blackboard  Files 


Figure  3a. 


CEMES  front-end  detailed  organizational  chart. 


RS232 


I 
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The  double  lines  and  arrows  in  Figures  3a  and  3b  represent 
communications  capabilities  and  directions  between  subsystems 
within  each  computer.  The  single  lines  and  arrows  represent 
communications  and  data  flow  between  the  two  computers  and  the 
operator.  Note  that  the  connection  between  the 'two  computers  is 
via  a  RS232  line,  a  portion  of  which  appears  in  each  figure. 

This  separation  is  necessary  because  the  double  lines  represent 
communications  implemented  differently  than  the  communications 
represented  by  single  lines.  Communications  represented  by 
double  lines  are  not  accessible  to  the  operator  during  normal 
operation  of  the  CEMES  system. 

The  double-lined  communications  also  represent  the  object- 
oriented  programming  style  used  for  CEMES  development.  This 
style  involves  programming  in  terms  of  independent  chunks,  or 
objects,  that  directly  correlate  with  the  major  aspects  and 
divisions  of  the  programming  problem  (see  Stefik  and  Bobrow, 
1986).  This  division  is  straightforward  with  CEMES,  each 
subsystem  being  programmed  as  its  own  object  or  collection  of 
obj  ects . 

The  LISP  language  implementation  on  the  Symbolics  3640  provides 
direct  object-oriented  programming  constructs.  The  communication 
protocol  used  between  objects  is  referred  to  as  message  passing. 
Therefore,  the  subsystem  objects  programmed  on  the  Symbolics  3640 
use  a  message-based  inter-  and  intra-object  communications 
protocol..  However,  the  BASIC  language  implementation  on  the  HP 
9000  does  not  provide  for  a  direct  object-oriented  programming 
style.  It  is  a  multitasking  language  which  was  used  to  simulate 
the  features  of  object-oriented  programming.  This  was  accom¬ 
plished  by  coding  an  object  as  an  independent  program  and  using 
the  event  semaphores  provided  by  the  HP  BASIC  language  for  mess¬ 
age  passing.6 

It  is  important  to  note  that  a  blackboard  appears  in  both 
Figures  3a  and  3b.  The  core  program  blackboard  object  appearing 
in  the  Symbolics  3640  portion  of  CEMES  (i.e.,  Figure  3b,  the 
actual  expert  system  portion)  represents  the  blackboard  shown  in 
the  general  design  in  Figure  1.  The  blackboard  shown  for  the  HP 
9000  programs  (Figure  3a)  is  a  duplicate  with  some  additional 
data  files.  This  type  of  design  was  selected  to  facilitate  the 
speed  and  efficiency  of  communications  between  the  subsystems  on 
the  two  computers  and  avoid  a  potential  bottleneck  that  might 


6  Event  semaphores  generally  are  used  to  signal  control  or 
availability  of  shared  devices  in  multitasking  environments. 

For  example,  two  programs  running  concurrently  may  need  to  use 
a  single  device  such  as  a  printer.  Since  both  programs  cannot 
access  the  printer  concurrently,  a  semaphore  is  used  as  signal 
between  the  programs  to  indicate  the  availability  of  the  shared 
printer. 
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degrade  real-time  operation.  The  communications  programs  for 
each  computer  maintain  congruency  between  the  two  blackboards  by 
transmitting  only  those  data  required  or  changed.  The  scheduling 
of  the  communications  is  controlled  by  the  expert  system  portion 
of  CEMES  on  the  Symbolics  machine. 
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The  CEMES  expert  system 

The  process  control  loop  and  subsystem  taskings 

The  primary  operational  portion  of  CEMES  is  the  expert  system 
that  resides  on  the  Symbolics  3640  LISP  machine.  As  noted  in  the 
previous  section,  the  CEMES  expert  system  is  composed  of  the  man¬ 
agement,  logistics,  trend,  diagnostics,  and  treatment  subsystems 
(Figures  1  and  3b)  that  act  as  independent  knowledge  sources  with 
the  blackboard  serving  as  a  shared  data  repository.  However, 
CEMES  does  not  use  a  dynamic  blackboard  control  strategy  (see 
Hayes-Roth,  1985) .  In  a  dynamic  blackboard-based  expert  system, 
each  knowledge  source  operates  independently  based  on  the  infor¬ 
mation  on  the  blackboard.  Knowledge  sources  generate  activation 
records  which  are  prioritized  for  completion  by  a  scheduling 
mechanism.  Therefore,  the  order  of  processing  knowledge  source 
activation  records  changes  with  and  in  response  to  the  contin¬ 
gencies  generated  by  the  problem. 

CEMES,  however,  uses  a  solution-based  strategy  realized  in  a 
process  control  loop  that  activates  each  knowledge  source  (i.e., 
subsystem)  at  the  appropriate  time  when  its  task  must  be  com¬ 
pleted.  In  addition,  the  CEMES  blackboard  is  unidimensional  in 
that  it  consists  of  levels  of  abstraction  containing  "raw"  data 
(vital  signs) ,  intermediate  results  (system  status  data) ,  and 
final  results  (diagnoses  and  display  messages) .  There  is  no 
time,  solution  interval,  or  other  second  dimension  as  is  often 
the  case  for  systems  based  on  a  blackboard  control  architecture.7 

The  process  control  loop  is  relatively  straightforward  and 
largely  based  on  the  requirements  for  medical  diagnosis  and 
treatment  (from  Landon,  1986).  The  process  control  loop  is 
diagrammed  in  Figure  4.  It  should  be  noted  easily  that  the  sub¬ 
system  organization  in  terms  of  objects  (Figure  3b)  directly 
corresponds  with  the  principal  steps  of  the  process  control  loop 
(Figure  4).  This  reflects  the  object-oriented  programming  style 
and  maintains  a  direct  and  visible  relationship  between  program 
function  and  code  structure.  Each  step  in  the  process  control 
loop  will  be  explained  along  with  the  tasking  assignments  of  the 
various  subsystems  for  each  step  in  the  loop. 

CEMES  first  obtains  the  necessary  biomedical  data  through  the 
front-end  sensor  subsystem.  The  front-end  sensor  subsystem  has 
design  for  both  stimulating  automatic  biomedical  sensor  equipment 
and  entering  vital  sign  data  through  a  menu-driven  program.  The 
specific  operation  of  the  front-end  sensor  will  be  covered  in 
detail  in  the  section  "The  CEMES  front-end."  It  should  be  noted 


7  Conversely,  the  solution  interval  dimension  is 
irrelevant  because  the  process  control  loop  executes  the 
actions  of  the  various  subsystems  in  a  strict  order. 
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Request  data 


Sensor  and  data  analysis 
Determine  diagnosis 
Determine  trend 
Treatment  analysis 
Effectors  analysis 
Treatment  selection 
Update  histories 

Perform  required  treatment  actions 
Recycle  - 


Figure  4.  CEMES  expert  system  process  control  loop. 


that  vital  sign  data  currently  are  limited  to  blood  pressure, 
pulse  pressure  (the  difference  between  systolic  and  diastolic 
blood  pressure),  pulse,  and  respiration  rate  (i.e.,  the  key 
vital  signs  for  hemorrhagic  shock) . 

Following  data  collection,  the  logistics  subsystem  determines 
whether  or  not  the  new  vital  sign  data  is  valid.  This  involves  a 
straightforward  analysis  of  the  vital  signs  with  respect  to 
physiological  range  limitations  (e.g.,  a  pulse  of  400  is  invalid) 
and  consistency  (e.g.,  diastolic  BP  should  not  exceed  systolic 
BP) .  Whatever  vital  signs,  if  any,  that  are  found  to  be  invalid 
are  so  marked  on  the  blackboard  and  not  used  by  subsequent 
analyses . 

The  next,  and  principal,  step  is  for  the  expert  system  to 
determine  a  diagnosis  with  respect  to  shock  and/or  nerve  agent 
contamination  (or  to  indicate  if  the  casualty  is  stable,  should 
that  be  the  case) .  The  diagnostics  subsystem  is  tasked  with 
completing  this  step.  The  diagnostic  inference  procedure,  to  be 
explained  later,  uses  whatever  data  is  available  after  validation 
by  the  logistics  subsystem.  The  diagnostics  subsystem  also 
retains  all  knowledge  representations  of  the  various  possible 
diagnoses  of  shock  and  contamination.  The  form  of  these 
representations  will  be  covered  in  the  following  subsection. 
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The  fourth  step  is  for  the  trend  subsystem  to  determine  a 
diagnostic  trend.  This  is  accomplished  both  by  examining 
relationships  between  successive  diagnoses  and  analyzing  the 
vital  sign  history  of  the  casualty.  The  trend  analysis  can  have 
three  directions  (improving,  deteriorating,  or  unchanging)  and 
two  magnitudes  (catastrophic  or  gradual)  for  a  combined  total  of 
five  trend  outcomes  (i.e.,  the  unchanging  direction  has  no 
magnitude) .  The  trend  subsystem  also  maintains  a  medical  history 
that  includes  vital  sign  data,  diagnostic  results,  and  trend 
results . 

After  determination  of  the  trend,  the  treatment  subsystem 
performs  a  preliminary  analysis  to  determine  any  required 
treatment  (consisting  of  an  IV  fluid  infusion  rate  and/or 
atropine  dose) .  The  treatment  subsystem  uses  various  treatment 
models  representing  treatment  parameters  for  fluid  infusion  or 
drug  dosage.  These  models  are  attached  to  corresponding 
diagnostic  representations.  Therefore,  the  appropriate  treatment 
model  is  preselected  by  the  diagnosis.  However,  the  selection  of 
a  final  treatment  regimen  (derived  from  the  model)  is  temporarily 
suspended  pending  a  second  logistical  analysis  of  the  effector 
subsystem. 

Following  preliminary  treatment  analysis,  the  logistics 
subsystem  completes  a  second  analysis  to  determine  if  the 
appropriate  logistical  conditions  have  been  met  for  delivery  of 
the  proposed  treatment  regimen.  If  IV  fluid  infusion  is  required 
by  the  treatment  analysis,  then  a  determination  must  be  made  to 
see  if  the  required  equipment  is  available  and  able  to  administer 
the  requested  treatment.  This  analysis  involves  determining  if 
the  proper  number  of  IV  infusion  units  are  attached,  signaling 
the  hookup  of  IV  infusion  units  whdn  required,  tracking  the 
administration  and  depletion  of  IV  fluid,  and  providing 
indications  for  IV  bag  replacement  as  necessary.  For  example, 
the  treatment  model  attached  to  the  current  diagnosis  may  require 
IV  fluid  infusion  when  no  IV  lines  have  been  established.  The 
effectors  analysis  senses  this  problem,  provides  the  necessary 
messages  to  signal  the  medic  or  physician  that  an  IV  line  is 
required,  and  informs  the  treatment  subsystem  so  that  it  won't 
erroneously  assume  that  the  proper  treatment  can  be  administered. 
The  logistics  object  uses  system  hardware  representations  to 
accomplish  its  task. 

After  the  effectors  analysis,  the  treatment  subsystem  finalizes 
the  IV  infusion  rate  and/or  atropine  dose.  It  writes  the  neces¬ 
sary  information  on  the  blackboard  for  transmission  to  the 
effector  subsystem  for  implementation. 

The  process  control  loop  is  concluded  by  updating  all  medical 
histories  in  the  various  subsystems  maintaining  such  accounts  and 
providing  the  proper  signals  to  effect  the  treatments  or  update 
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the  graphics  display  as  required.  The  process  control  loop  then 
recycles  after  a  1-minute  real-time  interval. 

The  process  control  loop  itself  is  mediated  through  inter-and 
intrasubsystem  object-oriented  message  passing.  The  method 
(i.e.,  code)  containing  the  control  loop  currently  resides  as 
part  of  the  manager  object  in  the  management  subsystem.  This 
loop  also  serves  as  point  of  entry  and  exit  for  external  control 
of  CEMES  on  the  Symbolics  LISP  machine. 


Knowledge  representation 

The  principal  representational  technique  used  in  the  CEMES 
expert  system  is  the  frame.  Each  diagnosis,  treatment,  and 
system  component  model  is  represented  using  a  frame-based  form. 
Each  treatment  model  frame  is  attached  to  a  complementary  injury 
model  frame,  with  the  system  component  models  being  independent 
frames . 

The  central  knowledge  component  in  CEMES  is  the  injury  frame 
because  it  serves  as  the  "glue"  that  relates  the  various 
subsystems  and  their  taskings.  The  basic  form  of  each  injury 
frame  is  shown  in  Figure  5.  The  features  of  each  injury  frame 
include  a  slot  holding  a  list  of  diagnostic  properties,  a  group 
of  slots  for  trend  analysis,  a  single  slot  that  identifies  the 
treatment  procedure  for  that  particular  diagnosis,  and  a  slot 
holding  an  ordinal  measure  of  severity  on  a  range  of  1  through 
10.  An  actual  injury  frame  for  class  3  hemorrhagic  shock  is 
given  in  Figure  6  to  provide  an  example  of  a  frame  with  specific 
information  entered  into  the  various  slots. 

The  diagnostic-property  slot  provides  information  used  by  the 
diagnostic  inference  heuristic  for  activation  of  the  frame  as  the 
current  diagnosis.  Various  vital  signs  and  their  ranges  that 
indicate  the  injury  are  listed.  Since  only  quantitative  vital 
signs  are  used,  a  numerical  range  for  each  sign  is  given.  The 
inference  procedure  then  uses  this  information  when  determining 
if  the  frame  should  be  activated. 

The  trend  slots  provide  both  property  lists  for  trend 
directions  and  pointers  that  represent  this  injury's  relationship 
with  other  injuries  when  such  relationships  exist  a  priori.  The 
trend  inference  procedures  apply  this  information  to  determine 
trend  direction  and  magnitude  using  an  algorithm  to  be  discussed 
later. 
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Injury-name:  <name-of-injury> 

Diagnostic-properties:  ((property  range)  .  ..) 

Trends : 

Properties: 

Getting-worse:  ( (property  direction)  .  .  . ) 

Getting-better:  ((property  direction)  .  ..) 
Relations : 

Worse-than:  <name-of-injury> 

Much-worse-than :  <name-of-inj  ury> 

Better-than:  <name-of-injury> 

Much-better-than:  <name-of-injury> 
Current-direction : 

Range :  <worse , much-worse , better , much-better, 

unchanged> 

Default:  unchanged 

Treatment-procedure :  <procedure-name> 

Severity-index: 

Range:  <1-10> 


Figure  5.  Injury  frame  organization. 


Injury-name :  Class-3-hemorrhagic-shock 

Diagnostic-properties:  ( (bp-sys  80-89)  (pulse  121-180) 
(pulse-pressure  0-30)  (respiration  29-33)) 

Trends : 

Properties : 

Getting-worse:  ((bp-sys  <)  (pulse  >) ) 

Getting-better:  ( (bp-sys  >)  (pulse  <) ) 
Relations : 

Worse-than:  Class-2-hemorrhagic-shock 

Much-worse-than :  Class-l-hemorrhagic-shock 

Better-than :  Class-4-hemorrhagic-shock 

Much-better-than:  None 
Current-direction:  unchanged 
Treatment-procedure:  Class -3 -shock- treatment 
Severity-index:  8 


Figure  6.  Class  3  hemorrhagic  shock  diagnostic  frame. 


The  treatment-procedure  slot  contains  the  name  of  the 
appropriate  treatment  model  frame  for  the  diagnosis  modeled  by 
the  injury  frame.  The  treatment  models  also  are  represented  by 
frames  in  the  general  form  shown  in  Figure  7.  All  treatment 
frames  have  the  slots  outlined  under  the  "Basic  frame"  heading  in 
Figure  7.  The  basic  slots  provide  for  a  treatment  procedure  name 
and  adjustments  to  the  treatment  based  on  the  results  of  the 
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trend  analysis.  These  adjustments  have  a  direction  (+,  -)  and  a 
numerical  amount  in  cubic  centimeters  per  hour  (cc/hr)  for  IV 
fluid  and  milligrams  (mg)  for  atropine. 


BASIC  FRAME - 

Treatment-name :  <name-of-treatment> 
Trend-adjustments : 

Unchanged:  (direction, amount) 

Worse:  (direction, amount) 

Much-worse:  (direction, amount) 

Better:  (direction, amount) 

Much-better:  (direction, amount) 


ADDITIONAL  SLOTS  FOR  IV  FLUID  TREATMENT- 

Properties : 

IV-units-required : 

Range:  <0,1,2> 

Default:  1 

IV-rate-range:  (min, max) 

Range:  <100-6000> 

IV-blood: 

Range:  <indicated, not-indicated> 


ADDITIONAL  SLOTS  FOR  DRUG  TREATMENT- 
Properties : 

Dosage:  <amount  in  units  appropriate  for  drug> 
Vector :  IV 


Figure  7.  Treatment  procedure  frame  organizations. 


Each  treatment  frame  also  has  additional  slots  for  treatment 
properties  that  depend  upon  whether  the  treatment  is  IV  fluid  or 
atropine  (i.e.,  drug).  The  properties  slots  for  IV  fluid  treat¬ 
ment  contain  information  on  the  number  of  IV  infusion  units  re¬ 
quired,  the  range  of  IV  infusion  rates  possible,  and  whether  or 
not  blood  transfusions  are  indicated.  The  iv-rate-range  slot 
provides  practical  lower  and  upper  bounds  in  cc/hr  for  the  admin¬ 
istration  of-  fluid  for  the  particular  injury.  Absolute  lower  and 
upper  bounds  currently  are  limited  by  equipment  considerations  (0 
and  6000,  respectively).  IV-blood  is  a  simple  indicator  for 
transfusions  based  on  the  average  amount  of  blood  loss  necessary 
to  produce  the  severity  of  shock  being  treated.  This  information 
is  used  to  advise  attending  medical  personnel  of  the  need  for  a 
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transfusion  since  CEMES  does  not  manage  blood  transfusions.  Fig¬ 
ure  8  provides  an  example  of  a  treatment  frame  for  class  3  hem¬ 
orrhagic  shock. 


Treatment-name :  Class-3-shock-treatment 

Trend-ad j  ustments : 


Unchanged:  (+ 

Worse:  (+ 

Much-worse:  (+ 

Better:  (- 

Much-better:  (- 

Properties : 

IV-units- required : 
IV-rate-range : 
IV-blood: 


1000) 

1000) 

1500) 

1000) 

1000) 


(3000,6000) 

indicated 


Figure  8.  Class  3  hemorrhagic  shock  treatment  frame. 


The  properties  slots  for  drug  treatments  include  the  dosage  as 
measured  in  units  appropriate  for  the  drug  to  be  administered 
(which  is  indicated  in  the  treatment  procedure  name) .  The  vector 
slot  indicates  how  the  drug  is  to  be  administered.  At  present, 
atropine  is  administered  through  an  IV  piggyback  line.  The  vec¬ 
tor  slot  is  present  to  allow  future  iterations  of  CEMES  to  in¬ 
clude  a  nebulizer  or  other  means  to  administer  drugs. 

The  various  hardware  system  components  in  CEMES  also  are  re¬ 
presented  by  frames.  Unlike  the  frames  for  injuries,  the  hard¬ 
ware  frames  are  independent  and  do  not  have  relational  pointers. 
Presently,  only  automated  IV  fluid  and  intravenous  drug  admin¬ 
istration  units  are  represented  in  CEMES.8  The  various  biomed¬ 
ical  sensor  units  do  not  have  a  representation  in  CEMES.  The 
sensor  units  are  investigated  through  simple  algorithmic  analyses 
of  the  data  they  produce. 

Figure  9  shows  the  frame  organizations  for  the  various  IV 
hardware  units.  As  with  the  treatment  frames,  there  are  basic 
frame  slots  common  to  all  IV  hardware  units,  and  specific  slots 
depending  upon  whether  the  unit  delivers  fluid  or  a  drug.  All 
hardware  frames  contain  a  type  slot  which  indicates  what  the 
hardware  unit  delivers.  The  is-attached  slot  is  an  indicator  for 
attachment  to  the  casualty.  The  is-functioning  slot  indicates 
whether  the  hardware  unit  is  function  properly,  not  functioning 


8  An  IV  administration  unit  is  assumed  to  consist  of  an  IV 
bag  containing  appropriate  solution  (usually  Ringer's  lactate), 
tubing  and  needle  for  fluid  delivery,  and  an  automated  pump 
that  generates  fluid  flow  at  the  rate  determined  by  CEMES. 
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BASIC  FRAME - 


Type: 

Range:  <IV, atropine> 
Is-attached: 

Range:  <yes,no> 

Default:  no 
Is-functioning: 

Range:  <yes , no , problem> 

Default:  no 

Absolute-start-time :  <cycle-number> 


ADDITIONAL  SLOTS  FOR  IV  FLUID  UNIT  HARDWARE- 

Relative-start-time :  <cycle-number> 
Number-of-renewals:  <number> 

Fluid-remaining-this-bag : 

Range:  <0-1000> 
Current-administration-rate : 

Range:  <0-3000> 


ADDITIONAL  SLOTS  FOR  IV  DRUG  TREATMENT  HARDWARE- 

Amount -remaining: 

Range:  <0-1000> 

Mixture-ratio:  <number> 

Current-dosage:  cnumber  in  appropriate  units> 


Figure  9.  Treatment  hardware  frame  organizations. 

(e.g.,  out  of  fluid),  or  if  there  is  a  problem  (e.g.,  actual 
fluid  flow  does  not  match  signalled  fluid  flow,  indicating  a 
possible  blockage) .  The  absolute  start  time  slot  provides  the 
cycle  number  when  the  hardware  unit  was  attached  successfully  to 
the  casualty. 

The  specific  slots  for  IV  fluid  delivery  hardware  include  a 
relative-start-time  slot  which  is  the  cycle  number  when  the  cur¬ 
rent  IV  fluid  bag  was  started.  The  number-of-renewals  slot  is 
the  number  of  IV  fluid  bags  delivered  prior  to  the  current  bag. 
The  fluid-remaining  slot  holds  the  amount  of  fluid  left  in  the 
current  bag,  while  the  current-administration-rate  slot  holds  the 
current  delivery  rate  in  cc/hr  for  the  IV  fluid  unit  (which  is 
not  necessarily  equal  to  the  total  infusion  rate  if  more  than  one 
IV  fluid  unit  is  attached  to  the  casualty) . 

The  specific  slots  for  intravenous  drug  delivery  include  a  cur¬ 
rent-dosage  slot  which  holds  the  amount  of  the  drug  being  de¬ 
livered  on  any  given  cycle  in  units  appropriate  for  that  drug  (mg 
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for  atropine) .  The  other  slots  are  specific  to  the  intravenous 
delivery  of  a  drug.  Generally,  drugs  given  this  way  are  dis¬ 
tributed  in  premixed  IV  fluid  bags  at  a  specific  ratio.  For 
example,  an  atropine  bag  may  have  lOmg  of  atropine  mixed  for 
every  lOOcc  of  fluid.  Therefore,  delivery  of  lmg  atropine  re¬ 
quires  intravenous  injection  of  lOcc  of  atropine  bag  fluid.  The 
mixture-ratio  slot  provides  the  ratio  of  drug  to  fluid  and  is 
used  for  calculating  how  much  fluid  must  be  delivered  to  obtain 
the  required  dose.  The  amount-remaining  slot  holds  the  fluid 
remaining  in  the  drug  mixture  bag. 


Inference  procedures 

The  inference  procedures  used  by  the  CEMES '  expert  system  are 
different  in  both  technique  and  use  from  the  process  control 
loop.  Whereas  the  process  control  loop  governs  the  order  of  task 
completions  in  CEMES,  the  inference  procedures  govern  the  reason¬ 
ing  of  the  various  subsystems  with  respect  to  diagnoses,  trends, 
etc. 

The  basic  inference  technique  used  in  CEMES  is  a  check  and 
eliminate  heuristic  which  has  been  outlined  in  flow-chart  form  in 
Figure  10. 9  The  method  works  as  follows.  Initially,  all  injury 
frames  are  entered  into  a  current  candidate  list.  The  heuristic 
starts  by  selecting  a  vital  sign  based  on  its  importance  for 
diagnosing  shock  or  contamination.10  The  current  value  of  the 
selected  vital  sign  is  compared  with  the  range  constraints  for 
that  vital  sign  as  given  in  the  diagnostics  property  list  of  each 
injury  frame  in  the  current  candidate  list.  If  the  current  vital 
sign  value  does  not  fall  within  the  acceptable  range,  then  that 
injury  frame  candidate  is  marked  for  elimination  from  the  current 
candidate  list  (i.e.,  the  frame  must  fail  to  be  marked  for  elim¬ 
ination.  If  it  has  no  constraints  for  the  vital  sign,  then  it 
will  remain  a  candidate.)  After  all  injury  frames  in  the  current 
candidate  list  have  been  checked  with  respect  to  the  selected 
vital  sign,  those  injury  frames  marked  for  elimination  are  re¬ 
moved  from  the  current  candidate  list.  If  only  one  injury  frame 
is  left,  it  then  becomes  the  diagnosis.  If  all  current  injury 
frames  in  the  candidate  list  are  marked  for  elimination,  then  the 


9  This  elimination  scheme  is  adapted  from  a  theory  of 
choice  first  described  by  Tversky  (1972) .  He  referred  to  it  as 
the  "elimination  by  aspects"  choice  process.  A  complete 
theoretical  treatment  of  various  choice  and  selection  processes 
can  be  found  in  Landon  (1983). 

10  The  ordering  for  shock  is  systolic  blood  pressure, 
pulse  pressure  (the  difference  between  systolic  and  diastolic 
blood  pressure) ,  pulse,  and  respiration  rate.  Pulse  is  the 
only  sign  checked  for  contamination. 
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one  with  the  greatest  severity  index  becomes  the  diagnosis.  If 
more  than  one  injury  frame  remains  after  those  marked  for  elimi¬ 
nation  have  been  removed  from  the  current  candidate  list,  another 
vital  sign  is  selected  for  examination  and  the  elimination  pro¬ 
cess  is  repeated  on  the  reduced  candidate  list.  "  If  there  re¬ 
mains  more  than  one  injury  frame  in  the  candidate  list  after  all 
vital  signs  have  been  checked,  then  the  injury  frame  with  the 
greatest  severity  index  becomes  the  diagnosis. 

The  check  and  eliminate  method  of  inference  was  selected  due  to 
its  capability  for  completing  a  diagnosis  during  degraded  mode 
operation  (i.e.,  inference  with  incomplete  data,  as  opposed  to 
incomplete  knowledge) .  For  example,  any  prototypical  rule-based 
system  using  chaining  would  collapse  as  less  and  less  information 
was  available  in  the  database  (i.e.,  matches  would  be  impossible 
to  obtain  or  the  knowledge  base  would  have  been  expanded  to  in- 


High 


Control  Strategy 

Figure  10.  Check  and  eliminate  inference  procedure. 
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elude  rules  accounting  for  all  possible  combinations  of  the 
available  vital  sign  data) .  The  elimination  technique  has  both 
an  advantage  of  speed  and  a  robustness  when  various  vital  sign 
data  are  unavailable.  That  is,  when  a  vital  sign's  data  is 
marked  as  invalid  it  effectively  does  not  exist  'and  is  removed 
from  the  vital  sign  list  prior  to  entering  the  check  and  elimi¬ 
nate  inference  procedure  (a  very  simple  thing  to  do) .  Therefore, 
the  missing  vital  sign  has  no  bearing  on  the  diagnosis  because  it 
is  never  checked.  Conversely,  if  the  most  important  vital  sign 
data  are  available  and  the  diagnostic  constraints  are  mutually 
exclusive  across  most  injury  frames,  elimination  down  to  a  single 
candidate  will  be  fairly  quick  and  avoid  all  sorts  of  confirm¬ 
atory  procedures  and  mechanisms. 

A  second,  and  critical,  point  concerns  the  concurrent  diagnosis 
of  shock  and  chemical  contamination.  Chemical  contamination,  of 
itself,  cannot  be  sensed  by  CEMES  but  must  be  signalled  as  a  pos¬ 
sibility  by  the  attending  medic  or  physician.  The  principal 
vital  sign  used  in  determining  the  severity  of  contamination  is 
pulse.  However,  the  effect  of  contamination  is  to  depress  pulse, 
a  contraindication  of  shock.  Therefore,  pulse  should  not  be  used 
to  diagnose  shock  under  the  presence  of  contamination,  effec¬ 
tively  causing  a  degraded  mode  diagnosis  for  shock.  This  is  ac¬ 
complished  by  removing  pulse  from  the  vital  sign  list  when  shock 
is  diagnosed.  When  contamination  is  diagnosed,  only  pulse  is 
entered  in  the  vital  sign  list. 

In  addition  to  diagnostic  inference,  CEMES  also  incorporates 
trend  inference  mechanisms  to  determine  the  current  diagnostic 
trend.  Recall  there  are  three  directions  (improving,  deter¬ 
iorating,  and  unchanging)  and  two  magnitudes  (catastrophic  and 
gradual)  for  a  trend  outcome.  The  conditions  for  trend  direction 
are  provided  by  the  current  injury  frame  in  terms  of  properties 
and  relations  (Figure  5) . 

The  trend  inference  generally  is  straightforward.  The  previous 
cycle's  diagnosis  (kept  by  the  trend  object)  is  checked  to  see  if 
it  is  the  same  as  the  current,  active  diagnosis.  If  it  is,  then 
the  vital  signs  are  checked  by  the  elimination  method  described 
above  against  the  trend  property  lists  to  determine  direction. 

It  is  generally  the  case  that  each  vital  sign  has  opposite  in¬ 
dications  for  an  improving  or  deteriorating  direction,  and  so  the 
general  direction  can  be  determined  quickly.  However,  medical 
requirements  sometimes  dictate  that  more  than  one  sign  (usually 
at  least  systolic  blood  pressure  and  pulse)  satisfy  the  trend 
constraints  before  a  direction  is  confirmed.  In  such  cases,  the 
elimination  inference  procedure  continues  until  the  required 
number  of  constraints  are  failed  by  either  the  improving  or 
deteriorating  direction.  If  both  the  improving  and  deterior¬ 
ating  directions  fail,  then  the  trend  direction  defaults  to  un¬ 
changing. 
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Trend  magnitude  is  determined  through  straightforward  algo¬ 
rithmic  techniques  accomplished  concurrently  with  directionality 
checking.  Catastrophic  magnitude  is  indicated  if  the  current 
vital  sign  value  deviates  from  the  previous  vital  sign  value  or 
the  median  of  the  previous  five  values  by  10  or 'more.  Gradual 
magnitude  is  indicated  by  a  strict  increasing  or  decreasing 
ordering  of  the  vital  sign  values  over  the  last  five  cycles  if 
such  an  ordering  does  not  meet  the  catastrophic  magnitude  con¬ 
straints.  If  the  direction  indicated  is  unchanged,  then  magni¬ 
tude  is  irrelevant.  Conversely,  if  neither  catastrophic  nor 
gradual  magnitude  is  found  (as  indicated  by  failure  to  meet  the 
algorithmic  requirements) ,  then  the  direction  is  unchanged. 

In  the  cases  where  the  previous  (i.e.,  last  cycle's)  diagnosis 
is  not  the  same  as  the  current  injury  frame,  the  previous  injury 
frame  is  checked  against  the  trend  relations  of  the  current  act¬ 
ive  diagnosis.  If  a  match  is  found,  then  the  trend  is  estab¬ 
lished  by  which  category  of  match  was  obtained  (i.e.,  worse-than 
indicates  a  gradual  deterioration,  much-worse-than  indicates  a 
catastrophic  deterioration,  etc.  See  Figure  5) .  If  a  match  is 
not  found,  then  the  trend  defaults  to  unchanged.  That  is,  if  the 
current  diagnosis  has  no  relation  with  the  previous  cycle's 
diagnosis,  then  there  is  no  trend.  A  trend  cannot  be  established 
in  a  single  cycle. 

The  final  type  of  inference  made  by  CEMES  is  the  selection  of  a 
treatment.  This  consists  of-  selection  of  an  appropriate  IV  fluid 
infusion  rate  if  IV  fluid  treatment  is  indicated  by  the  active 
treatment  model  frame  and/or  an  atropine  dose.  The  selection  of 
an  IV  infusion  rate  has  three  principal  steps.  First,  the  rate 
is  set  to  at  least  the  minimum  required  by  the  treatment  model 
(given  by  the  iv-rate-range  slot) .  Next,  this  rate  is  adjusted 
up  or  down  according  to  the  trend  adjustment  given  by  the  slot 
corresponding  to  the  current  trend.  The  rate  is  then  reset  to 
the  minimum  or  to  the  maximum  if  the  adjustments  cause  it  to  ex¬ 
ceed  those  bounds.  Note  that  the  absolute  maximum  for  the  system 
is  6000cc/hr,  while  the  absolute  minimum  is  0  if  no  IV  fluid  in¬ 
fusion  units  are  attached,  or  lOOcc/hr  if  one  is  attached  (to 
maintain  an  open  line) . 

Recall  that  via  the  process  control  loop,  a  final  IV  infusion 
rate  is  determined  after  an  effectors  analysis  by  the  logistics 
subsystem.  If  the  treatment  subsystem  has  requested  a  positive 
IV  infusion  rate,  the  current  treatment  model  frame  is  checked  to 
see  how  many  IV  units  are  required  (i.e.,  the  iv-units-required 
slot) .  The  IV  unit  hardware  frames  then  are  checked  to  see  if 
the  required  units  are  attached  and  functioning.  If  they  are  not 
attached,  a  message  is  printed  on  the  graphics  display  informing 
the  medic  or  physician  the  casualty  requires  an  IV  line  to  be 
established  for  treatment.  If  they  are  attached  but  malfunction¬ 
ing  or  out  of  fluid,  appropriate  messages  are  displayed.  Depend¬ 
ing  upon  the  outcome  of  the  effectors  analysis,  the  logistics 
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subsystem  provides  an  appropriate  message  for  the  treatment  sub¬ 
system,  which  then  readjusts  the  IV  infusion  rate  if  necessary. 

Any  atropine  dosage  that  might  be  required  is  selected  in  a 
more  straightforward  fashion.  The  treatment  model  frames  for 
contamination  simply  state  the  dose  required.  However,  the 
nature  of  intravenous  atropine  delivery  requires  that  it  be 
cycled  in  five  minute  intervals.  That  is,  consecutive  doses  of 
atropine  must  be  administered  at  least  five  minutes  apart.  The 
treatment  subsystem  maintains  timing  mechanisms  and  cues  to 
properly  effect  this  cycle. 
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The  CEMES  front-end 


The  process  control  loop  and  subsystem  tasking 

The  front-end  portion  of  the  CEMES  system  resides  on  the  HP 
9000  minicomputer.  The  front-end  is  responsible  for  controlling 
or  simulating  all  data  input  and  output  for  the  expert  system 
portion  on  the  Symbolics  LISP  machine.11  As  noted  in  the  pre¬ 
vious  section  "CEMES  general  design"  and  Figure  3a,  the  front- 
end  primarily  is  composed  of  the  sensor  and  effector  subsystems 
along  with  some  independent  programs  used  to  augment  CEMES  front- 
end  functions.  These  independent  programs  consist  of  the  Master 
Control  Program,  the  Graphics  Display  Generation  and  Control 
Program,  and  the  Communications  and  File  Transfer  Control  Pro¬ 
gram.12  The  function  of  each  of  these  programs  is  suggested  by 
their  respective  names,  although  more  detailed  explanations  will 
be  given  later.  As  in  the  expert  system  portion  of  CEMES,  the 
front-end  is  governed  by  a  process  control  loop  that  coordinates 
the  various  programs  that  comprise  the  front-end. 

The  CEMES  front-end  process  control  loop,  diagrammed  in  Figure 
11,  is  implemented  within  the  Communications  and  File  Transfer 
Program.  This  program  cycles  in  response  to  signals  received 
from  the  CEMES  expert  system  (i.e.,  in  one  minute  intervals). 

The  signals  function  as  either  data  requests  or  information 
updates.  A  data  request  signal  indicates  that  current  front-end 
blackboard  information  should  be  transmitted  to  the  expert  system 
for  processing  (i.e.,  the  start  of  a  new  cycle).  These  data  con¬ 
sist  of  current  vital  signs,  sensor  hardware  status  messages,  and 
effector  hardware  status  messages.  Information  updates  contain 
graphics  display  updates  and/or  effector  control  information. 

Data  request  signals  always  precede  information  updates  (i.e., 
consistent  with  the  expert  system  process  control  loop.  See 
Figure  4.) 

The  front-end  process  control  loop  has  five  major  steps  (Figure 
11) .  Upon  receiving  a  data  request  signal  from  the  expert  sys- 


11  This  section  is  intended  to  cover  the  function  of  the 
front-end  subsystems  and  programs.  It  is  not  intended  to  serve 
the  dual  purpose  of  a  user's  manual.  However,  a  careful 
reading  of  this  section  should  provide  enough  information  to 
operate  CEMES  so  long  as  one  is  familiar  with  the  HP  9000  and 
Symbolics  3640  computers. 

12  Since  the  sensor  and  effector  subsystems  also  have 
their  own  independent  programs,  the  front-end  in  actuality 
consists  of  five  separate  programs,  not  including  the  various 
simulation  hardware. 
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Wait  for  data  request  from  expert  system 


Obtain  current  vital  signs,  sensor,'  and 
effector  status  messages  from  the  HP  blackboard 


Transmit  new  data  to  expert  system 

Wait  for  update  information 
to  be  sent  by  the  expert  system 

Post  new  information  on  the  HP  blackboard 


Generate  appropriate  signals  to  inform  other 
front-end  programs  that  the  HP  blackboard 
information  has  changed 


Recycle 


Figure  11.  CEMES  front-end  process  control  loop. 


tern,  the  Communications  and  File  Transfer  Control  program  obtains 
the  necessary  data  from  the  HP  blackboard.  These  data  are  en¬ 
coded  into  an  ASCII  file  for  transmission  to  the  expert  system  on 
the  Symbolics.  The  file  is  then  dispatched  along  a  RS232  con¬ 
nection  to  the  Symbolics  where  the  expert  system  decodes  the  file 
and  processes  the  new  information  as  discussed  in  the  previous 
section  "The  CEMES  expert  system." 

After  sending  the  requested  data,  the  Communications  and  File 
Transfer  Control  Program  enters  a  wait  state  until  update  infor¬ 
mation  is  received  from  the  expert  system.  When  the  update  in¬ 
formation  is  received,  the  Communications  and  File  Transfer  Con¬ 
trol  Program  enters  the  new  information  on  the  HP  blackboard. 
Appropriate  messages  are  sent  to  the  other  front-end  programs  to 
signal  that. the  blackboard  has  changed.  The  Communications  and 
File  Transfer  Program  then  enters  another  waiting  state  until  the 
expert  system  restarts  the  front-end  process  control  loop  by 
sending  another  request  for  new  data. 

It  should  be  noted  that  the  front-end  process  control  loop  is 
not  a  complete  description  of  the  operation  of  the  CEMES  front- 
end,  but  is  primarily  the  interface  mechanism  between  CEMES'  two 
major  components  (i.e.,  the  expert  system  and  the  front-end). 
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The  other  front-end  component  subsystems  and  programs  operate 
independently  (and  sometimes  continuously) .  These  other  front- 
end  components  will  be  individually  described  below. 


The  sensor  subsystem 

The  front-end  sensor  subsystem  consists  of  the  Sensor  Data 
Processing  Program,  various  hardware  interfaces  within  the  HP 
6942A  multiprogrammer,  and  the  vital  sign  and  casualty  simulation 
equipment.  A  diagram  showing  the  general  connections  and  organ¬ 
ization  of  the  sensor  simulation  equipment  is  given  in  Figure  12. 

The  sensor  subsystem  is  one  of  two  ways  that  front-end  sensor- 
based  information  can  be  obtained  by  CEMES.  The  second  way  is 
through  a  menu-based  program  that  will  be  described  in  detail  in 
the  following  section  "The  master  control  program."  The  sensor 
subsystem  simulates  a  real-time  environment,  whereas  the  menu- 
driven  program  provides  a  more  controlled  manner  of  entering 
data.  The  system  operator  is  queried  when  CEMES  is  first  acti¬ 
vated  as  to  which  method  of  data  acquisition  is  desired.  Of 
course,  in  an  operational  CEMES  all  data  will  be  acquired  auto¬ 
matically  through  the  sensor  subsystem. 

The  principal  function  of  the  sensor  subsystem  is  to  provide 
real-time  biomedical  signals  and  data  to  simulate  the  physiology 
of  a  casualty.  Since  operational  testing  of  CEMES  isn't  pos¬ 
sible,  the  sensor  subsystem  includes  various  off-the-shelf 
patient  simulators  (normally  used  to  provide  test  signals  for 
hospital  patient  monitoring  equipment)  and  some  custom-made 
equipment  that  enables  physiological  conditions  to  be  simulated 
as  though  noninvasive  sensors  were  taking  real  data  from  an 
actual  casualty.  The  signals  provided  by  the  casualty  simulation 
equipment  are  digitized  using  appropriate  hardware  in  the  HP 
6942A  multiprogrammer.  The  Sensor  Data  Processing  Program  con¬ 
verts  the  digitized  signals  to  numerical  form,  conducts  a  simple 
analysis  of  the  data's  validity,  and  enters  the  resulting  values 
in  the  appropriate  portion  of  the  HP  blackboard. 

Signal  data  is  provided  to  the  sensor  subsystem  through  either 
the  patient  simulators  or  the  signal  controller  box  (Figure  13) . 
Ranges  and  values  of  the  various  vital  signs  are  generally  re¬ 
stricted  on  the  patient  simulators.  Therefore,  the  signal  con¬ 
troller  provides  a  means  for  switching  that  equipment  out  of  the 
sensor  sampling  loop  and  adjusting  the  vital  signs  using  the 
various  dials  on  the  signal  controller  box.  When  the  controller 
box  switches  are  set  to  internal,  vital  signs  are  adjusted  using 
the  dials  on  the  controller  box  (as  appropriately  labeled) .  When 
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1,  LOVE( JOHN, MARY) 

John  loves  Mary,  Love  is  a  predicate  symbol, 

2,  SISTER(SUE, KATHY) 

Kathy  is  Sue's  sister.  Sister  is  a  predicate  symbol, 

3,  MARRIEDIfather(BOBBY),mother(BOBBY) 1 

Bobby's  father  is  married  to  Bobby's  mother,  Father 
and  mother  are  function  symbols.  Married  is  a  two- 
argument  predicate  symbol,  An  alternate  interpretation 
is  "John  is  married  to  Mary," 

4,  MARR IEDCfatherCSUE)^  father (KATHY ) ] 

Sue's  father  is  married  to  Kathy's  father. 

5,  CHILD(BOBBY) 

Bobby  is  a  child.  CHILD  is  a  single  argument  predicate 

SYMBOL , 

Figure  12.  Sensor  subsystem  equipment  diagram. 

1.  LIVESUOHN, HOUSE)  A  C0L0R(H0USE, BROWN) 

John  lives  in  a  brown  house, 

2.  LOCATION  HOUSE, MAPLE)  V  LOCATION  HOUSE, OAK) 

The  house  is  on  maple  or  oak  street. 

3.  ~  SISTER(MARY,SUE) 

Mary  and  Sue  are  not  sisters. 

4.  0WNS( JOHN, HOUSE)  — >  COLOR ( HOUSE, BROWN ) 

If  John  owns  the  house,  then  it  is  brown. 

5.  MARRIED(JOHN,MARY)  =  L0VE( JOHN, MARY) 

John  is  married  to  Mary  is  equivalent  to  John  loves  Mary. 

6.  father(BOBBY)  =  father(SUE) 

Bobby  and  Sue  have  the  same  father. 

Figure  13.  Sensor  subsystem  casualty  simulation  equipment. 
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switched  to  external,  vital  signs  are  obtained  from  the  various 
patient  simulators.  In  the  latter  case,  the  data  are  first 
routed  through  Tektronix  patient  monitors  as  a  first  step  in 
signal  analysis.  In  either  case,  the  signals  are  digitized 
through  the  multiprogrammer. 

The  Sensor  Data  Processing  Program  obtains  vital  sign  signal 
samples  from  the  multiprogrammer  every  2  seconds.  These  samples 
are  displayed  on  the  operator  interface  simulation  screen  (i.e., 
not  the  graphic  display)  so  that  the  system  operator  can  easily 
track  the  vital  sign  values  being  entered.  The  2-second  interval 
provides  a  substantially  finer  sampling  resolution  than  the  1- 
minute  processing  cycle  (which,  in  turn,  is  a  finer  resolution 
than  the  normal  time  course  of  human  physiological  change) .  The 
2-second  sampling  rate  provides  a  sufficient  number  of  samples 
for  an  analysis  of  the  sensor  data  for  spikes,  excessive  vari¬ 
ability,  and  other  indicators  of  sensor  malfunction.  When  new 
data  is  requested  by  the  expert  system  (i.e.,  step  one  in  the 
front-end  process  control  loop) ,  the  Sensor  Data  Processing  Pro¬ 
gram  analyzes  the  vital  sign  data  samples  taken  in  the  past  cycle 
to  determine  if  the  various  sensors  appear  to  be  functioning  pro¬ 
perly.  If  so,  the  new  vital  sign  values  are  entered  on  the  HP 
blackboard  (which  causes  their  display  on  the  CEMES  graphic  dis¬ 
play)  .  Otherwise,  appropriate  messages  are  provided  indicating 
that  a  sensor  has  malfunctioned.  The  algorithms  and  signal  pro¬ 
cessing  accomplished  by  the  Sensor  Data  Processing  Program  are 
covered  in  Landon  (1988b) . 

It  should  be  noted  that  when  first  starting  the  CEMES  system, 
the  system  operator  is  queried  as  to  whether  the  Sensor  Data 
Processing  Program  will  conduct  an  analysis  of  the  vital  sign 
data  samples  or  not.  Unless  one  is  aware  of  how  the  algorithms 
work  with  regards  to  flagging  a  malfunctioning  sensor,  the  pro¬ 
gram  may  interpret  fluctuations  in  the  vital  sign  data  due  to  a 
system  operator's  inappropriate  adjustment  of  vital  sign  values 
as  a  malfunctioning  sensor.  There  is  no  way  to  avoid  this  pit- 
fall  other  than  not  using  the  analysis  algorithms  of  the  Sensor 
Data  Processing  Program.  That  is,  a  full-fledged  test  scenario 
should  be  constructed  on  paper  before  running  a  complete  test  of 
CEMES  with  all  options  active. 


The  effector  subsystem 

The  front-end  effector  subsystem  consists  of  the  Treatment 
Hardware  Control  Program,  various  hardware  interfaces  within  the 
HP  6942A  multiprogrammer,  and  the  IV  pump  simulation  equipment. 

A  diagram  showing  the  general  connections  and  organization  of  the 
effector  simulation  equipment  is  given  in  Figure  14. 

The  principal  function  of  the  effector  subsystem  is  to  simulate 
the  delivery  of  IV  fluid  infusion  and  drug  treatments  to  the 
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casualty.  The  effector  subsystem  includes  various  off-the-shelf 
industrial  pumps,  actual  IV  tubing  and  needles,  and  fluid  con¬ 
tainers  that  are  used  to  simulate  the  delivery  of  IV  fluid 
(Figure  15) .  The  Treatment  Hardware  Control  Program  converts  the 
treatment  regimen  messages  received  from  the  expert  system  to 
control  signals  that  govern  the  fluid  pumping  rates  of  the  IV  in¬ 
fusion  pump  simulators. 

The  treatment  regimen  messages  sent  from  the  expert  system  con¬ 
sist  of  an  IV  fluid  infusion  rate  (in  cc/hr)  and  an  atropine  dose 
(in  cc,  if  required).  The  Treatment  Hardware  Control  Program 
converts  the  IV  infusion  rate  to  appropriate  control  signals  for 
the  HP  6942A  multiprogrammer  digital-to-analog  control  cards, 
which  in  turn  convert  the  control  signals  to  steady-state  current 
which  governs  the  pumping  rate  of  the  FMI  QA600  pumps  used  to 
simulate  the  automatic  infusion  of  fluids. 

Note  that  one  pump  is  used  for  IV  fluid  delivery  and  one  for 
atropine  piggyback  drug  infusion  (Figure  14).  Due  to  equipment 
limitations,  a  single  pump  is  used  with  a  two-place  manifold  to 
simulate  the  two  IV  infusion  units  assumed  by  the  expert  system 


1.  3  x i  MARRIED(x,  JOHN) 

There  exists  someone  x  such  that  x  is  married  to  John. 

2.  Vy:  MEMBERS, SMITH  FAMILY) 

For  all  people  y,  y  is  a  member  of  the  Smith  family. 

3.  3x:  MOTHERS  MARY)  A  SISTER(x,  SUE) 

There  exists  someone  x  such  that  x's  mother  is  Mary  and 
x's  sister  is  Sue. 

4.  3X3Y :  L0VE(x,y) 

There  exists  a  person  x  and  a  person  y  such  that  x  loves  y. 


Figure  14.  Effector  subsystem  equipment  diagram. 


1.  Every  city  has  a  dogcatcher  who  has  been  bitten 
by  every  dog  in  town. 

( Vx)  jdTY(x)— *-(3y)  |dOGCATCHER  (x,y)  A 
(Vz)j  jDOG(z)  A  LIVES-IN(x,z)]— -BIT(y,z) 

2.  AH  blocks  on  top  of  blocks  that  have  been  moved 
or  that  are  attached  to  blocks  that  have  been 
moved  have  also  been  moved. 

( Vx)  ( Vy )||BLOCK(x)  A  BLOCK(y)  A[ONTOP(x,y)V 

ATTACHED  (x,y,)]  vj-~MOVED(x)j 

Figure  15.  Effector  subsystem  IV  infusion  simulation 
equipment . 


to  be  available.  However,  the  expert  system  operates  as  though 
there  were  two  independent  IV  infusion  units  with  independent 
fluid  bags  (even  though  the  amount  fluid  is • essentially  limitless 
in  this  prototype) .  The  Treatment  Hardware  Control  Program  turns 
the  atropine  pump  on  and  off  as  appropriate  to  deliver  the  re¬ 
quired  amount  of  simulated  atropine  fluid  mixture. 

The  simulation  of  IVs  also  involves  signalling  when  infusion 
units  are  attached,  when  fluid  bags  are  replaced,  and  other 
hands-on  aspects  of  IV  administration.  Explanations  of  these 
additional  effector-oriented  simulation  requirements  will  be  pro¬ 
vided  in  the  following  section  "The  master  control  program." 


The  graphic  display 

The  graphic  display  is  generated  and  controlled  by  the  Graphics 
Display  Generation  and  Control  Program.  The  graphic  display  pro¬ 
vides  a  means  for  visually  displaying  the  status  of  CEMES  and  its 
various  operations  from  cycle  to  cycle.  The  task  of  the  Graphics 
Display  Generation  and  Control  Program  is  to  maintain  congruency 
between  the  information  in  the  HP  blackboard  and  the  information 
on  the  graphic  display.  An  example  of  the  graphic  display  is 
provided  in  Figure  16.  It  should  be  noted  a  display  of  this  com¬ 
plexity  may  or  may  not  be  included  in  a  field  operational  CEMES 
system.  This  particular  graphic  display  design  was  implemented 
to  provide  all  the  necessary  information  to  aid  in  CEMES '  design 
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and  testing.  There  are  five  major  areas  of  the  display,  each  set 
off  from  the  other  and  suitably  labeled. 

The  vital  signs  display  area  contains  the  current  vital  sign 
data,  which  is  defined  as  the  data  last  sent  to  "the  expert  system 
(i.e.,  it  may  not  be  the  most  recent  data,  which  is  defined  as 
the  data  from  the  last  sample  taken  by  the  sensor  subsystem) . 

Note  that  provisions  have  been  made  on  the  display  for  some  vital 
signs  that  aren't  yet  being  used  by  the  expert  system  (see  the 
following  section  "Future  developmental  directions"). 

The  elapsed  time  display  area  provides  several  time  indicators. 
The  principal  indicator  is  in  large  type  and  provides  the  amount 
of  time  the  casualty  has  been  attached  to  the  system  (i.e.,  a 
relative  measure) .  Below  that  are  indicators  for  when  the 
casualty  was  attached  to  the  system  (the  start  time,  an  absolute 
measure)  and  for  when  the  display  was  last  updated  (the  last  dis¬ 
play  update,  an  absolute  measure) .  Note  that  the  last  display 
update  time  is  not  always  to  the  last  cycle  time.  The  graphics 


1 ,  ~  X)=  X 


2.de  Morgan’s  Laws: 


MX  AY)  XV  ~  Y 
MXVY)  XA-Y 

3.  Distributive  Law: 

Y  A(X  VZ)  =  (  Y  AX)  V ( Y  AZ) 

4.  Commutative  Law: 


5. 

6 . 
7. 


YAX  =  X AY 


Contrapositive  Law: 


Y  — *■  X  =  ~  X — ~  Y 
~{3X)P(X)  =  (VX)  ~ 
(VX)P(X)s  (VY)P(Y) 


P(X)] 


Figure  16.  CEMES  graphic  display  example. 


display  sometimes  will  be  updated  in  response  to  an  operator 
generated  signal  of  some  external  event  that  occurs  independently 
of  the  normal  cycle. 

The  system  status  display  area  is  where  the  expert  system  dis¬ 
plays  various  messages  having  to  do  with  the  casualty's  diag¬ 
nosis,  the  administered  treatment  regimen  (because  the  effector 
subsystem  may  not  have  the  capability  for  delivering  the  pre- 
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f erred  regimen) ,  logistical  indicators,  and  any  additional  mes¬ 
sages  deemed  necessary.  These  four  classes  of  messages  are 
separated  and  displayed  under  appropriate  labels  that  define 
display  subareas  within  the  system  status  area.  .  The  various 
messages  are  color  coded  white,  green,  yellow,  or  red  depending 
upon  the  type  of  message.  The  default  display  color  is  white, 
with  system  OK  messages  in  green,  cautionary  or  advisory  messages 
in  yellow,  and  severe  or  warning  messages  in  red.  Advisory  and 
warning  messages  also  are  accompanied  by  additional  visual  cues 
in  the  form  of  a  header  (as  in  the  "ALERT"  header  shown  in  the 
Figure  16  example)  and  auditory  cues  with  differing  frequencies 
and  temporal  characteristics. 

The  hardware  status  display  area  provides  a  pictorial  display 
of  the  location  and  status  of  the  various  sensor  and  effector 
units  that  have  been  attached  to  the  casualty.  The  icons  and 
labels  for  each  hardware  item  are  color  coded  to  provide  visual 
cues  as  to  their  status.  Green  indicates  the  hardware  is  OK  and 
functioning  properly.  Yellow  indicates  a  problem  or  a  malfunc¬ 
tion.  Red  indicates  the  hardware  item  is  not  functioning  (for 
whatever  reason) . 

The  hardware  status  display  area  in  the  example  (Figure  14) 
shows  various  devices  that  serve  as  examples  for  what  could  be 
included  in  an  operational  front-end.13  An  automated  BP  cuff  is 
attached  to  provide  blood  pressure  measurements.  The  PMC  label 
represents  a  personal  monitor  and  communicator  which  provides 
heart  rate  and  respiration  rate.  This  particular  casualty  has 
had  two  IV  units  attached,  one  of  which  is  getting  low  on  fluid. 
He  also  has  had  an  atropine  piggyback  line  established. 

The  last  display  area  is  the  trend  graph  at  the  top  of  the 
display.  This  graph  provides  a  chart  upon  which  the  various 
vital  sign  data  can  be  plotted  for  a  visual  indication  of  how 
those  signs  have  changed  across  time.  The  example  in  Figure  16 
shows  systolic  blood  pressure  and  heart  rate.  The  values  plotted 
are  absolute  values,  with  the  scale  shown  at  the  left  of  the 
graph.  The  intermittent  vertical  lines  represent  10  minute 
intervals  in  real-time.  At  present,  the  Graphics  Display 
Generation  and  Control  Program  only  can  display  systolic  blood 
pressure  and  heart  rate  on  the  trend  graph. 

Note  the  trend  graph  has  room  to  display  1  hour's  worth  of  data. 
This  shows  the  graph's  particular  configuration  for  the  first 
hour  of  operation.  After  the  first  hour,  the  horizontal  scale  on 


13  The  example  in  Figure  16  is  not  meant  to  indicate  that 
all  of  the  equipment  shown  is  either  necessary  or  will  be  assumed 
to  part  of  an  operational  CEMES  front-end.  There  are  both 
scientific  and  practical  questions  that  must  be  addressed  with 
regard  to  how  to  noninvasively  monitor  certain  physiological  signs. 
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the  graph  condenses  to  represent  2  hours'  worth  of  data  (i.e., 
the  number  of  vertical  lines  doubles) .  The  last  hour's  data  is 
redrawn  on  the  new  scale  with  new  data  being  graphed  on  the  end 
of  the  previous  hour.  That  is,  there  is  always  as  much  data  as 
is  available,  or  at  least  1  hour's  worth  of  data'  with  the  new 
data  being  added  on  as  received. 

The  trend  graph  area  also  displays  the  total  amount  of  IV  fluid 
that  has  been  administered  to  the  casualty  along  with  the  total 
amount  of  atropine.  This  is  to  provide  additional  information 
for  a  physician  or  medic  should  hands-on  interruption  of  the 
system  be  required. 


The  master  control  program 

The  principal  program  for  interacting  with  CEMES  is  the  Master 
Control  Program  shown  on  Figure  3a.  This  program  provides  all 
the  various  menu-driven  capabilities  for  control  and  interaction 
through  the  front-end.  An  organizational  chart  of  the  various 
menus  available  in  the  Master  Control  Program  is  provided  in 
Figure  17.  The  specific  menus  themselves  are  shown  in  Figure  18 
exactly  as  they  appear  on  the  console  CRT.  The  menus  serve  as 
labels  for  the  softkeys  provided  on  the  HP  9000  keyboard.  A  push 
of  the  appropriate  softkey  initiates  the  particular  action  indi¬ 
cated  by  the  key's  label.  An  explanation  of  the  Master  Control 
Program  will  proceed  through  an  explanation  of  what  can  be  done 
within  each  menu.14 

The  main  menu  provides  a  starting  point  of  selecting  the  parti¬ 
cular  activity  to  be  accomplished.  The  "System  Startup"  selection 
begins  execution  of  the  front-end  programs  (as  opposed  to  loading 
and  running  the  Master  Control  Program  which  requires  some  know- 


Main  menu 


Operator 

interaction 

menu 


System 

interaction 

menu 


Text  file 

maintenance 

menu 


Figure  17.  Master  Control  Program  menu  hierarchy. 


14  To  reiterate,  this  discussion  is  not  intended  as  a 
user's  or  instructional  manual  for  the  operation  of  the  CEMES 
front-end,  even  though  the  explanation  of  the  various  menu 
selections  of  the  Master  Control  Program  will  provide  a  basic 
knowledge  of  how  to  operate  CEMES  from  the  front-end. 
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ledge  of  the  HP  9000  minicomputer) .  When  the  "System  Startup" 
selection  is  made,  the  Master  Control  Program  executes  a  series 
of  functions  that  boots  the  remainder  of  the  front-end  systems. 
When  appropriate,  the  booting  functions  ask  the  .system  operator 
if  menu  driven  vital  sign  input  is  desired.  Answering  "No"  in¬ 
itiates  automatic  sampling  as  discussed  in  the  previous  section 
"The  sensor  subsystem."  If  automatic  sampling  is  requested,  the 
booting  functions  will  also  ask  if  the  sensor  functionality 
checks  should  be  activated.  The  booting  functions  will  then 
complete  the  front-end  initialization  and  prepare  CEMES  for  oper¬ 
ation.  Selecting  the  "System  Shutdown"  option  on  the  Main  menu 
will  then  stop  operation  of  the  front-end  programs  and  reset  the 
HP  9000  for  normal  computer  operations.15 

The  "File  Backup"  option  on  the  Main  menu  provides  a  means  for 
automatically  generating  floppy  disk  backups  of  all  the  front-end 
programs  and  files  that  normally  reside  on  the  HP  9000's  internal 
hard  disk.  A  full  backup  requires  three  properly  formatted  5.25- 
inch  floppy  disks,  each  of  which  is  inserted  into  the  internal 
floppy  disk  drive  on  cues  provided  by  the  backup  program.  The 
backup  program  returns  to  the  main  menu  upon  completion.  The 
last  three  selections  on  the  main  menu  provide  branches  to  the 
other  menus  of  the  Master  Control  Program. 

The  main  menu  "Txt_file  Maint"  selection  branches  to  the  text 
file  maintenance  menu  (Figure  18) .  This  menu  is  used  to  control 
operations  with  respect  to  the  four  text  files  that  are  part  of 
the  front-end  blackboard  (see  Figure  3a) .  These  four  text  files 
contain  the  various  text  messages  that  appear  in  the  system 
status  portion  of  the  graphic  display.  The  expert  system  signals 
the  display  of  the  various  messages  in  the  four  subareas  of  the 
system  status  display  area  through  appropriate  codes  that  are 
transmitted  to  the  front-end  on  each  cycle.  The  Graphics  Display 
Generation  and  Control  Program  interprets  the  various  codes, 
retrieves  the  proper  messages  from  the  text  files,  and  generates 
the  appropriate  graphics  for  the  display.16 


15  Note  that  to  setup  the  computers  for  CEMES  operation 
requires  that  the  Master  Control  Program  first  be  loaded  and 
run  on  the  HP9000  (without  selecting  the  "System  Startup" 
option) ,  then  the  expert  system  be  started  on  the  Symbolics 
3640,  and  lastly  the  "System  Startup"  option  be  selected  from 
the  Main  menu  of  the  Master  Control  Program. 

16  The  text  message  codes  are  the  actual  information 
stored  in  the  blackboard  file  after  being  parsed  from  the 
updated  information  file  by  the  Communications  and  File 
Transfer  Control  Program.  That  is,  the  only  place  where  the 
text  messages  appear  in  readable  form  is  on  the  graphic  display 
or  in  a  hardcopy  dump  of  the  text  file. 
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Text  file  maintenance  operations  proceed  by  first  selecting  a 
file  to  work  on  (the  "Select  File"  choice  on  the  menu) ,  and  then 
completing  whatever  actions  are  desired.  The  "Add  Text"  selec¬ 
tion  branches  to  a  routine  for  adding  new  text  messages  to  the 
file.  The  "Output  Hardcopy"  selection  produces  'a  listing  of  all 
text  messages  currently  in  the  file  on  the  internal  thermal 
printer  of  the  HP  9000.  The  "Change  Text"  selection  branches  to 
a  routine  allowing  changes  to  be  made  to  existing  text  messages. 

As  can  be  inferred  from  the  names  of  the  four  text  files 
(Figure  3a) ,  each  corresponds  to  messages  that  are  displayed  in 
the  corresponding  subarea  of  the  system  status  display  area. 
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Figure  18.  Master  Control  Program  menus. 


Each  text  file  can  contain  up  to  400  different  messages  with  no 
more  than  52  characters  per  message  (including  spaces  and  punctu- 
uation) .  The  operation  of  the  expert  system  and  system  program¬ 
mer  determine  the  types  of  messages  entered  into  each  file. 

The  "System  Interact"  selection  on  the  main  menu  branches  to 
the  system  interaction  menu  (Figure  18) .  The  system  interaction 
menu  is  used  when  menu-driven  control  of  the  sensor  and  effector 
subsystems  is  desired  during  a  normal  test  run  of  CEMES . •  The 
"Vital  Signs"  selection  provides  for  menu-driven  input  of  vital 
sign  values  to  the  front-end  blackboard.  This  is  used  in  lieu  of 
the  automatic  sampling  of  vital  signs  from  the  sensor  subsystem. 
The  program  will  not  allow  you  to  take  this  selection  if  auto¬ 
matic  sampling  was  requested  during  the  boot-up  operation. 
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The  "Treat  Hard"  and  "Sensor  Hard"  selections  on  the  System 
Interaction  menu  provide  for  a  means  to  artificially  signal  a 
malfunction  of  some  front-end  piece  of  equipment.  Only  strict 
malfunctions  can  be  signalled,  as  other  problems_  are  a  domain  of 
analysis  for  the  expert  system.  The  "Sensor  Hard"  selection  will 
also  let  the  operator  signal  that  a  particular  sensor  is  attached 
or  unattached  (note  that  an  unattached  sensor  cannot  provide 
data,  and  the  expert  system  will  react  accordingly) . 

The  "DO  IT"  selection  is  taken  when  the  changes  to  the  front- 
end  made  through  the  "Vital  Signs,"  "Treat  Hard,"  and  "Sensor 
Hard"  selections  are  complete.  That  is,  no  entry  is  permanent 
and  entered  on  the  front-end  blackboard  until  the  "DO  IT"  selec¬ 
tion  is  made.  The  desired  changes  will  not  show  up  on  the 
graphic  display  until  "DO  IT"  is  selected.  This  is  primarily  a 
safety  mechanism  to  prevent  unwanted  changes  or  mistakes. 

The  "Output  Hardcopy"  selection  provides  either  a  'snapshot' 
printed  output  on  the  internal  thermal  printer  of  the  data  cur¬ 
rently  in  the  front-end  blackboard,  or  a  color  graphics  plot  of 
the  current  graphic-  display  screen  on  an  HP  7475A  six-pen  plotter 
(see  Appendix  A)  that's  attached  to  the  HP  9000.  The  plotted 
output  is  drawn  by  a  special  program  that's  loaded  and  run  when  a 
plotted  output  is  desired.  It  takes  several  minutes  and  runs 
independently  of  CEMES  once  started.  It  should  be  noted  that 
once  the  plot  is  started,  it  must  finish  before  another  can  be 
started.  That  is,  plots  of  successive  graphic  display  screens 
are  not  possible. 

The  Operator  Interaction  menu,  entered  by  selecting  "Operator 
menu"  on  the  Main  menu  or  System  Interaction  menu,  provides  a 
means  for  simulating  certain  actions  an  attending  medic  or 
physician  would  have  to  complete  at  CEMES  request  in  an  opera- 
ional  environment.  Since  an  actual  casualty  cannot  be  attached 
to  the  system  for  testing,  this  menu  allows  actions  such  as  IV 
attachment,  bag  replacement,  etc.  to  be  simulated.  These  menu 
selections  are  fairly  self-explanatory. 

The  "Iv  hookup"  selections  signal  that  the  appropriate  IV  unit 
has  been  attached  to  the  casualty  as  requested  by  CEMES.  Unit  1 
should  always  be  attached  before  unit  2.  "IV  bag  replaced"  sig¬ 
nals  that  an  empty  IV  bag  has  been  replaced  with  a  full  bag  as 
requested  by  CEMES.  "IV  fluid"  increase  or  decrease  will  change 
the  current  IV  infusion  rate  by  250  cc/hr  in  the  signalled  di¬ 
rection.  This  change  will  be  independent  of  the  rate  established 
by  the  expert  system.  These  changes  essentially  are  overrides  to 
the  rate  established  by  the  expert  system  and  should  be  used  with 
extreme  caution.  The  "Atrop"  push  and  disable  selections  provide 
overrides  for  atropine  delivery.  The  push  causes  1  mg  of  atro¬ 
pine  to  be  delivered  (if  the  atropine  piggyback  is  functioning) 
right  now.  The  disable  selection  inhibits  the  expert  system  from 
delivering  atropine.  The  "Chem  cont"  selection  provides  a  signal 
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that  chemical  agent  contamination  is  present.  CEMES  has  no  abi¬ 
lity  to  sense  chemical  agent  presence  independently.  This  selec¬ 
tion  must  be  made  before  CEMES  will  diagnose  for  the  delivery  of 
atropine.  The  "Hookup  atrop"  selection  signals  that  the  atropine 
piggyback  has  been  hooked  up  to  the  casualty  as  -requested  by 
CEMES . 


"GO"  is  a  special  selection  used  when  CEMES  is  booted  on  the 
front-end.  After  the  boot  up  process,  CEMES  enters  a  waiting 
state.  The  front-end  is  operational,  but  the  expert  system  will 
wait  for  the  "GO"  signal  which  indicates  that  the  initial  vital 
sign  values  and  front-end  hardware  configuration  has  been  com¬ 
pleted.  That  is,  after  CEMES  has  been  booted,  you  can  input 
initial  vital  sign  values  and  change  the  status  of  various  front- 
end  hardware.  Selecting  "GO"  the  starts  the  normal  1-minute 
cycling  of  CEMES.  CEMES  will  automatically  start  cycling  after  5 
minutes  if  "GO"  is  not  signalled. 

It  should  be  noted  that  there  is  no  demonstration  mode  for 
CEMES  at  this  stage  as  there  was  for  Phase  I.  All  of  the  CEMES 
programs  have  been  designed  around  the  1-minute  cycle  time. 

There  is  no  way  to  change  this  cycle  time  and  maintain  the 
integrity  of  CEMES  operation.  CEMES  is  demonstrated  by 
developing  appropriate  short-term  casualty  scenarios  and  running 
them  as  tests  of  the  system. 
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Future  developmental  directions 

Although  CEMES  has  been  developed  to  the  point  of  demonstrating 
all  the  essential  elements  of  an  automated  emergency  medicine 
system,  there  are  several  additional  aspects  that  could  be  de¬ 
signed  into  the  system.  As  pointed  out,  one  of  CEMES '  opera¬ 
tional  requirements  was  to  fit  into  the  continuum-of-care  and 
far-forward  care  concepts  governing  the  evacuation  and  treatment 
of  casualties.  CEMES  meets  those  requirements  in  the  minimal 
configuration  documented  here.  However,  the  concept  of  CEMES  can 
be  extended  beyond  what  was  described  here. 

For  example,  the  graphic  display  includes  provisions  for  blood 
gas  measurement  (partial  pressure  of  oxygen  and  carbon  dioxide) 
and  urine  output.  These  signs  can  be  used  to  govern  artificial 
respiration  and  fine-tuning  of  IV  fluid  infusion,  respectively. 
Assisted  respiration  is  particularly  relevant  for  the  treatment 
of  nerve  agent  contaminated  casualties. 

Such  medical  systems  as  respirators,  foley  catheters,  etc., 
while  not  necessarily  appropriate  for  far-forward  operations 
(although  this  is  an  unresolved  operational  question) ,  can  be 
configured  as  add-ons  to  the  base  CEMES  system.  That  is,  the 
base  CEMES  system,  as  described  in  this  report,  could  be  deployed 
as  far-forward  as  possible  to  aid  in  initial  trauma  and  shock 
care.  As  the  casualty  is  evacuated,  additional  medical  care 
modules  could  be  added  at  various  levels  in  the  evacuation.  It 
is  quite  possible  that,  at  far  rear  areas,  enough  modules  might 
be  added  so  that  each  casualty  has  his  own  self-contained 
critical  care  facility. 


Summary 

This  report  describes  the  exploratory  development  of  a  combat 
emergency  medicine  expert  system  (CEMES) .  The  principal  aspects 
of  the  design  and  operation  of  CEMES  have  been  documented.  CEMES 
can  diagnose  and  simulate  IV  treatment  for  all  classes  of  hemor¬ 
rhagic  shock.  Additional  mechanisms  for  the  diagnosis  of  chem¬ 
ical  agent  contamination,  atropine  treatment  for  contamination, 
and  degraded  mode  operation  have  been  included. 
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Appendix  A 
Manufacturers'  list 


Bio-Tek  Instruments,  Inc. 
1  Mill  Street 
Burlington,  VT  05401 

Dynatech  Nevada,  Inc. 

2000  Arrowhead  Drive 

P.0.  Box  1925 

Carson  City,  NV  89701 

Fluid  Metering,  Inc. 

29  Orchard  Street 

P.0.  Box  179 

Oyster  Bay,  NY  11771 

Hewlett-Packard  Company 
Building  5 
4700  Bayou  Blvd. 
Pensacola,  FL  32503 

Symbolics,  Inc. 

Department  803 
555  Virginia  Road 
Concord,  MA  01742 

Tektronix,  Inc. 

P.0.  Box  500 
Beaverton,  OR  97077 
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